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Abstract 


This memo describes the management and operational requirements for 
the address and routing parameter area ("arpa") domain. The "arpa" 
domain is used to support a class of infrastructural identifier 
spaces, providing a distributed database that translates elements of 
a structured name space derived from a protocol family to service 
names. The efficient and reliable operation of this DNS space is 
essential to the integrity of operation of various services within 
the Internet. The Internet Architecture Board (IAB) has the 
responsibility, in cooperation with the Internet Corporation for 
Assigned Names and Numbers (ICANN), to manage the "arpa" domain. 
This document describes the principles used by the IAB in undertaking 
this role. 


1. Introduction 


The Domain Name System (DNS) [1] [2] is predominately used to 
translate a structured textual identifier into a protocol-specific 
value. It uses the structure embedded within a hierarchical 
identifier space to create a distributed database, where every node 
within the database corresponds to a node within the name structure. 
The most prevalent role of the DNS is to store a set of name to 
address translations, allowing a domain name to be translated to an 
IP address. The DNS is also used to store a number of other 
translations from hierarchically structured identifier spaces into 
target values of various types. 
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The DNS is also capable of supporting a translation in the opposite 
direction, from protocol values to the names of service entities. 
One approach in using the DNS in this fashion has been to transform 
protocol values into a hierarchically structured identifier space, 
and then use these transformed protocol value names as a DNS lookup 
key into the appropriate DNS name hierarchy. A common use of this 
mechanism has been the reverse of the name to address lookup, 
allowing for an IPv4 address to be used to look up a matching domain 
name. For example, the IP address 128.9.160.55 can be associated 
with the domain name "www.iab.org." by creating the DNS entry 
55.160.9.128.in-addr.arpa." and mapping this entry, via a DNS PTR 
record, to the value "www.iab.org.". 


The resolution of protocol objects into service names is used by a 
number of applications to associate services with a particular 
protocol object. The correct and efficient operation of these 
applications is dependent on the correct and efficient operation of 
the associated "arpa" domain name servers. 


2. The "arpa" domain 


The "arpa" domain was originally established as part of the initial 
deployment of the DNS, to provide a transition mechanism from the 
Host Tables that were common in the ARPANET, as well as a home for 
the IPv4 reverse mapping domain. During 2000, the abbreviation was 
redesignated to "Address and Routing Parameter Area" in the hope of 
reducing confusion with the earlier network name. 


The Internet Architecture Board (IAB), in cooperation with the 
Internet Corporation for Assigned Names and Numbers (ICANN), is 
currently responsible for managing the Top Level Domain (TLD) name 
"arpa". This arrangement is documented in Appendix A. This domain 
name provides the root of the name hierarchy of the reverse mapping 
of IP addresses to domain names. More generally, this domain name 
undertakes a role as a limited use domain for Internet 
infrastructure applications, by providing a name root for the mapping 
of particular protocol values to names of service entities. This 
domain name provides a name root for the mapping of protocol values 
into lookup keys to retrieve operationally critical protocol 
infrastructure data records or objects for the Internet. 


The IAB may add other infrastructure uses to the "arpa" domain in the 


future. Any such additions or changes will be in accordance with the 
procedures documented in Section 2.1 and Section 3 of this document. 
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This domain is termed an "infrastructure domain", as its role is to 
support the operating infrastructure of the Internet. In particular, 
the "arpa" domain is not to be used in the same manner (e.g., for 
naming hosts) as other generic Top Level Domains are commonly used. 


The operational administration of this domain, in accordance with the 
provisions described in this document, shall be performed by the IANA 
under the terms of the MoU between the IAB and ICANN concerning the 
TANA [3]. 


2.1 Criteria for "arpa" Sub-domains 


The "arpa" sub-domains are used for those protocol object sets 
defined as part of the Internet Standards Process [4], and are 
recommended to be managed as infrastructure protocol objects. 
Normally, the recommendation is to be made in the "IANA 
Considerations" section of the Internet Standard protocol 
specification. The recommendation should include the manner in which 
protocol objects are to be mapped into lookup keys, and 
recommendations to IANA concerning the operation of the "arpa" sub- 
domain in conjunction with the recommendations concerning the 
operation of the protocol object registry itself. 


The IESG consideration of a document which proposes the use of an 
"arpa" sub-domain shall include consideration of the "IANA 
Considerations" section. If the document is approved, the IESG will 
ask the IAB to request the IANA to add the corresponding protocol 
object sub-domain domain to the "arpa" domain, in accordance with RFC 
2860 [3], with administration of the sub-domain undertaken in 
accordance with the provisions described in this document. 


2.2 "arpa" Name Server Requirements 


As this domain is part of the operationally critical infrastructure 
of the Internet, the stability, integrity and efficiency of the 
operation of this domain is a matter of importance for all Internet 
users. 


The "arpa" domain is positioned as a top level domain in order to 
avoid potential operational instabilities caused by multiple DNS 
lookups spanning several operational domains that would be required 
to locate the servers of each of the parent names of a more deeply 
nested infrastructure name. The maximal lookup set for "arpa" is a 
lookup of the name servers for the "arpa" domain from a root server, 
and the query agent is then provided with a list of authoritative 
"arpa" name servers. 
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The efficient and correct operation of the "arpa" domain is 
considered to be sufficiently critical that the operational 
requirements for the root servers apply to the operational 
requirements of the "arpa" servers. All operational requirements 
noted in RFC 2870 [5] as they apply to the operational requirements 
of the root servers shall apply to the operation of the "arpa" 
servers. Any revision to RFC 2870 in relation to the operation of 
the root servers shall also apply to the operation of the "arpa" 
servers. 


Many of the servers that are authoritative for the root zone (or the 


"." zone) also currently serve as authoritative for the "arpa" zone. 
As noted in RFC 2870 [5], this arrangement is likely to change in the 
future. 


3. Delegation of "arpa" Sub-Domains 


While the decision as to which protocol elements are loaded into the 
"arpa" domain, and the hierarchical structure of such protocol 
elements, remains within the role of the IAB, the role of managing 
the sub-domain may be delegated by the IAB to an appropriate protocol 
management entity. 


The IAB shall only recommend the creation of "arpa" sub-domains 
corresponding to protocol entities where: 


- the delegation, and the hierarchical name structure, is described 
by an IETF Standards Track document [4], and 


- the use of the "arpa" domain is explicitly recommended in the 
"TANA Considerations" section of that document. 


The "IANA Considerations" section should include the name of the 
subdomain, the rules for how the subdomain is to be administered, and 
the criteria for entries within the subdomain. 


4. Current Status of "arpa" 


The "arpa" domain is used for the sub-domains "in-addr.arpa" [1], 
"ip6.arpa" [7] and "el64.arpa" [8]. 


Currently, the "arpa" zone is located on a subset of the root 
servers, and the zone is managed in accordance with these 
specifications. The IAB is working with ICANN, IANA, and the 
regional registries to move "arpa" and "in-addr.arpa" records from 
the root servers in accord with the RFC 2870 recommendation for 
exclusive use of those servers [5]. 
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The IPv4 reverse address domain, "in-addr.arpa" is delegated to the 
IANA. The "in-addr.arpa" zone is currently located on the same same 
subset of the root servers as "arpa". Sub-delegations within this 
hierarchy are undertaken in accordance with the IANA’s address 
allocation practices. 


The "ip6.arpa" IPv6é reverse address domain uses a method of 
delegation that is the same as is used for "in-addr.arpa", where the 
"ip6.arpa" domain is delegated to the IANA, and names within this 
zone further delegated to the regional IP registries in accordance 
with the delegation of IPv6 address space to those registries [6] 
ETI 


The "el64.arpa" domain is used to map E.164 style phone numbers into 
URIs. This mechanism is defined in RFC 2916 [9]. RFC 2916 notes 
that the provision that names within this DNS zone are to be 
delegated to parties according to ITU recommendation E.164 [10]. RFC 
3026 [8] describes the overall liaison arrangements between the IETF 
and ITU-T about the use of this domain. 


5. Infrastructure domains elsewhere in the DNS tree 


Any infrastructure domains that are located elsewhere in the DNS tree 
than as sub-domains of "arpa", for historical or other reasons, 
should adhere to all of the requirements established in this document 
for sub-domains of "arpa", and consideration should be given to 
migrating them into "arpa" as and when appropriate. 


6. Security Considerations 


The security considerations as documented in RFC 2870 [5], and any 
successors to that document, apply to the operation of the "arpa" 
servers. 


The security considerations specific to the E.164 subdomain are 
documented in Section 5 of RFC 2916 [9]. 


Any new subdomain delegation must adequately document any security 
considerations specific to the information stored therein. 


7. IANA Considerations 


As noted in section 3 of this document, the IAB may request the IANA 
to delegate the sub-domains of "arpa" in accordance with the "IANA 
Considerations" section of an IETF Standards Track document. This 
request falls under the scope of section 4 of the MoU between the 
IETF and ICANN concerning the IANA [3]. 
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Appendix A 
April 28, 2000 


Mr. Louis Touton 

Vice-President, Secretary, and General Counsel 
Internet Corporation for Assigned Names and Numbers 
4676 Admiralty Way, Suite 330 

Marina del Rey, CA 90292 


Re: Purchase Order No. 40SBNT067020: 
Administration of the arpa Top Level Domain 


Dear Mr. Touton: 


As noted in your organization’s quotation of February 2, 2000, the 
arpa Top Level Domain (TLD) exists in the root zone of the domain 
name system as a limited use domain currently consisting of one 
record, in-addr.arpa. On April 14, 2000, the Defense Advanced 
Research Projects Agency (DARPA), formerly known as the Advanced 
Research Projects Agency (ARPA), officially signaled its 
disassociation with the arpa domain and its understanding the domain 
would be used by the Internet Corporation for Assigned Names (ICANN) 
and Numbers and the Internet Architecture Board (IAB) for additional 
Internet infrastructure uses. 


In keeping with the DARPA understanding, we believe that the arpa 
domain should be made available for this specific, limited purpose. 
The Department of Commerce considers this an Internet Assigned 
Numbers Authority (IANA) function and has requested that the WHOIS 
entry for the arpa domain reflect IANA as the registrant. 


Purchase Order No. 40SBNT067020 provides that "[ICANN] will perform 
other IANA functions as needed upon request of DOC." As such, the 
Department of Commerce requests that, as part of the IANA functions, 
ICANN undertake administration of the arpa TLD in cooperation with 
the Internet technical community under the guidance of the IAB, as a 
limited use domain for Internet infrastructure applications, 
including the migration of Internet infrastructure applications that 
currently reside in the .int TLD. Further, as indicated by DARPA, 
the arpa TLD string should be given a different expansion such as 
"Address and Routing Parameter Area" to avoid any implication that 
DARPA has operational responsibility for the domain. 


If you have any questions, please do not hesitate to contact me. 


Sincerely, Karen Rose 
Purchase Order Technical Representative 
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Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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